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(54) Title: APPLICATION PROGRAMMING INTERFACE SYSTEM AND TECHNIQUE 



(57) Abstract 

A novel method of and system for heterogeneous con- 
nectivity and universal and generic interfacing for distributed 
applications and processes residing in a wide variety of com- 
puting platforms communicating over varied transport facili- 
ties, through an integrated set of lower-level programs and 
routines that handle specific services (message/data recovery, 
security, directory services, etc.) available from applications 
and processes within varied complex computing arid commu- 
nications environments, and without having to deal with the 
idiosyncrasies of differing networks, protocols, devices, multi- 
ple "standards", routing, recovery and other transport difficul- 
ties and differences. This is effected by novel single-function 
software modules or verbs, called application programming in- 
terface (API), that together provide a consistent and universal 
interface through which application programs/processes can ac- 
cess the messaging communications services in a manner that 
isolates the applications and processes from the confusing and 
fast-changing communications environment, as well as from 
differences in various computer operating systems, platforms 
and hardware. 
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APPLICATION PROGRAMMING INTERFACE SYSTEM AND TECHNIQUE 



10 



20 



The present invention relates to electronic messaging systems and techniques for 
providing messaging services between applications and processes, being more 
particularly concerned with providing a universal or generic approach for 
interfacing distributed applications and processes residing in a wide variety of 
computing platforms, and enabling communicating over one or more transport 
facilities as desired — providing for use within a multi-media, multi-platform and 
multi-network computing and communications environment. 

Background of the Invention 



Though the term "electronic messsaging" has come often to be interpreted 
as synonymous with "electronic mair, in the context of the present invention and 
this application, the term "messaging" is used in a much broader sense 
encompassing also any type of content; namely, the encapsulation of any data 
15 objects « text, graphics, data, digitized voice or image or the like together with 
delivery, utilization and identification information that 
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is needed to produce at each final destination, those 
activities specified by the encapsulated content. 

Heretofore, individual and specially tailored sof t- 
5 ware has been required for inter working and integrating 

distributed applications and processess and linking stand 
alone applications. The different computer platforms have 
required differently designed data/message transfer treat- 
ment and linking programs and processes running in a 
10 variety of environments and with a variety of communica- 
tions types or media, all specifically tailored to the 
particular equipment networks and protocols — and each 
being restricted to and useful for its environment only. 

15 Underlying the present invention is the surprising 

discovery that despite such wide and often disparate 
variety of equipments, networks, protocols, platforms and 
communications techniques and environments, each requiring 
its individualized treatment, there can be a universality 

20 or generic approach to the programmatic interfacing or 
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underlying message/data transport and recovery services 
that can indeed provide consistent, seamless and trans- 
parent connectivity betweeen applications and for pro- 
cesses residing in widely different computer platforms 
5 linked by a variety of different networks and protocols. 
This is referred to herein as heterogeneous connectivity 
for distributed applications and processes, with the elec- 
tronics messaging systems concept of the invention being 
referred to as "EMS". 

10 The highly novel approach of the present invention to 

attain this seemingly impossible task resides, in part, in 
an integrated set of software lower-level programs and 
routines that handle specific services - message/data re- 
covery, security, directory services, etc., available from 

15 applications and processes within varied complex computing 
and communications environments, and without having to 
deal with the i d i o s y n ch r a s i e s of differing networks, 
protocols, devices, multiple "standards", routing, 
recovery and other transport difficulties and differ- 

20 ences. This is effected in EMS, by isolating applications 
and processes from the increasingly confusing and fast- 
changing communications environment, as well as from 
differences in varying computer operating systems, and 
platforms and hardware. 
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The inherent problems underlying implementing 
communications programs between computer systems, make it 
very difficult to handle all of the i d i o s y n c h r a s i e s of 
different hardware, operating environments, protocols, and 

5 networks* Maintaining appropriate software as operating 
systems are upgraded and new communications features come 
to market is nearly impossible - especially when communi- 
cations are embedded in application programs. 

To obviate these difficulties, EMS has undertaken to 

10 provide : 

a) message/data queuing and communications ser- 
vices separated from application programs and processes; 

b) specifics of hardware and operating environment 
handled completely and transparently fey the communications 

^ services facility; and 

c) stable, consistent interface between applications 
and the communications environment that does not change 
every time a network or computing platform is added, 
changed or removed. 

20 
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The invention achieves a solution to this increasing- 
ly common, complex and costly problem through insulating 
both the developer and the user from the vagueries of the 
communications facilites and networks and from the speci- 

5 fics of the operating environment and hardware, EMS also 
provides access to the widest variety of communication 
facilities. In addition, EMS tracks the status of a 
message, and, depending on the facilites on the receiving 
side, can guarantee delivery to the destination applica- 

10 tion. 

Through the novel approach of the EMS technique, a 
middleware toolkit is provided consisting of a programma- 
tic interface and underlying message/data transport and 
recovery services that together provide the before- 

15 described consistent, seamless and transparent connecti- 
vity between applications and/or processes that reside in 
different computer platforms linked by different networks 
and protocols. The term "middleware" is used to connote a 
layer of software located between the networks, protocols 

20 and transport facilities available on a computing plat- 
form, and the applications or processes that require 
transport of messages and data to and from applications 
and processes on different computing platforms. The 
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inteRrated set of lower-level programs and routines that 
handle specific s e r vi ce s-mes s age /da t a recovery, security, 
directory services - within a complex computing and 
communications environment and that constitutes the "tool 
5 kit", enable 

Guaranteed data/message transfer - managing the 
transmission and receipt of messages and data so as 
to ensure absolutely that these are received by the 
10 intended destination; 



Most communications media supported - types of 
communication; media supported range from asynchro- 
nous dial-up modem communications to wireless RF ser- 
15 vices, such as ARDIS and RAM . Where there is a 

choice of media to use, EMS assists in deciding which 
one to employ . 

Most popular computing platforms supported- EMS 
20 software runs on most of the popular computing 

platforms to enable developers to link programs and 
processes running in a variety of environments. 
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Present day data communication systems mandate one 
type of protocol to get all the data across. The present 
invention, on the other hand, provides a scheme at the 
communication layer that allows for the management of mul- 
5 tiple communication facilities simultaneously. Upon los- 
ing one communication facility type, another communication 
facility type can be picked up to continue the sending of 
information. A management facility that manages what is 
called communication agents, attached to each type of com- 
10 munications facility, recognizes when and what is avail- 
able to be able to transmit data. It takes a packet of 
information, regardless of whether it all belongs to one 
message or is in different messages, stages it for 
delivery, and hands it off to the proper communication 
15 port that is available at that point in time, moving the 
data through in a continuous pipe or stream. By segment- 
ing the message into logical units of data related to one 
another by headers, if a communications facility, (for 
example TCPIP) is lost after one segment is sent, any 
20 other routes or communication facilities available to the 
environment are identified, and the next piece of data 
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will accordingly be sent along such, following preset 



guide-lines. A 



n upper layer protocol recognizes that data 



is related, but that it has been fragmented, sometimes 
oddly. It must be interperted , extracted and fitted 
5 together. Just as when analyzing proteins in genetics, 
when fracturing, it is desired to know what is missing 
from the chain so as to rebuild the chain to create the 



tion, a piece of missing data that fits in somewhere 
10 within the data chain can be requested by the receiving 
end from the transmiting end, no matter what the protocol 
that is being used, enabling i n t e r d i s bu r s eme n t of the 
movement of information or packets that belong to a single 
unified piece of information and across multiple paths 

^ and communication types, from end to end, and without the 
application having to know anything about the communica- 
tions facilities. Additionally, the present invention can 
run on multiple operating systems with exactly the same 
interface being presented to the application or the 
20 process or the user of the system. All of the specific 
devices, communications facilities and memory management 
are hidden from the users, providing a novel minimal 
A consistent communi c ation environment sitting on top of the 



gene . 



In similar fashion, in acccordance with the inven- 




operating system and facility. 
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Objects of Invention 

An object of the present invention, accordingly, is 
to provide a new and improved method of and system or 
5 apparatus and controlling software for electronic messag- 
ing that provides heterogeneous connectivity and a measure 
of universal or generic interfacing for distributed appli- 
cations and processes residing in a wide variety of 
different computing platforms, communicating over one or 
1° more different transport facilities. 

A further object is to provide such universal connec- 
tivity through the technique of isolating applications and 
processes from the communications environment with an 
integrated set of lower-level programs and routines that 
15 handle specific se rvi ces-mes sage /data recovery, security, 
directory services, etc. - within complex computing and 
communications environments without dealing with the idio- 
syncrosies of differing networks, protocols, devices, mul- 
tiple "standards 0 , routing, recovery and other transport 
20 problems . 

Other and further objects will be explained herein- 
after and are more particularly delineated in the appended 
claims. 
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Summa r y 

In summary, however, from one of its broader aspects, 
the invention embraces a method of electronically messag- 

5 ing between computers by he t e r o g e n e ou s 1 y and universally 
interfacing distributed applications and processes resid- 
ing in a wide variety of differing computer platforms and 
communications transport facilities of various types, that 
comprises, providing a set of s i n g 1 e - f un c t i o n software 

10 modules controlled by a preselected set of verbs that 
together provide a consistent application prog r ammi ng 
interface between the application/process and the communi- 
cations facility and through which application programs/ 
processes can access the electronic messaging; under the 

15 

control of the set of module verbs, first queuing and 
routing messages and data flowing from and to the sending 
and receiving computer ap p 1 i c a t i ons / pr o ce s s es and monitor- 
ing the delivery status thereof, and then co mm unicating 
the routed messages and data through a communication agent 

20 f or each coramuni ca t ion transport facility; and providing 
c oram on me ssaglng functions for all communication agents 
independently of and without user concern for the speci- 
fics of the various communications facilities and their 
characteristics* 

25 Preferred and best mode designs and details of system 

construction and operation and modified forms thereof are 
later presented. 
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D rawlngs 

The invention will now be described with reference to 
the accompanying drawings, Fig. 1 of whichis a block dia- 
5 gram schematically illustrating the EMS messaging services 
and functions in accordance with a preferred embodiment of 
the inven t ion ; 

Fig. 2 is a similar diagram illustrating the messag- 
ing system of the invention within a communications 
10 envi ronment ; 

Fig. 3 is a messaging process diagram tracing from 
(1) start-up and initialization of the EMS systems, 
through (2) sending messages, (3) checking status, and (4) 
receiving messages; 
* 5 Fig- A is a diagram similar to Fig. 2, but showing 

the message header (EMH), router control block (RCB) and 
interface control block (ICB) locations; 

Fig, 5 is a bl*ock diagram showing the sending - 
receiver computer messaging through a network or other 
transport facility; 

Fig. 6 is a combined apparatus and flow diagram 
illustrating the outgoing messaging process and steps; 



20 
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Fig. 7 is a similar diagram of the incoming message 
processing; 

Figs. 8 through 17 are operational flow charts of 
steps carried out by the software in effectuating the API 
5 control verbs COMMIT , DELETE, FREEBUF , GETBUF , INITIALIZE, 
PURGE, RECEIVE, SEND, STATUS and TERMINATE, respectively; 
and 

Fig. 18 is a chart summarizing the current hetero- 
geneous connectivity features of the present constructions 
10 0 f the invention for a variety of existing commercial 
platforms and communication protocol/ network systems. 

Description of Preferred Embodiment(s) of Invention 

15 j t i 5 now i n order to describe how the novel results 

of the present invention are attained in integrating into 
each application that will use EMS messaging services 
three main steps. First, designing a messaging user 
interface to each particular application/process that 

^ satisfies the requirements of its users, and which deter- 
mines how the particular programs will utilize EMS messag- 
ing capabilities. Secondly, integrating EMS into each 
application/ process using EMS automatic programming inter- 
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face (API) verbs* In general, this requires only the 
loading of a data buffer with message and message 
processing instructions and calling the appropriate verb, 
with linking procedure on the particular platform 
5 providing access to the EMS automatic programming 

interface API verbs. Thirdly, configuring and testing 
EMS, using appropriate testing guidelines. In general, 
the manner in which EMS is used will be the sane across 
all platforms and environments, differing only where 

10 platform requirements make such differences unavoidable. 
The technique or method underlying the invention 
provides all of the tools needed for intelligent delivery 
of data between applications and processes by a 
simple, consistent programmatic interface rather than 

15 dozens of network, protocol and device complexities. If 
communicating applications or processes change from 
mainframe to a Unix box, no change is required for 
applications and processes. EMS simply uses the change in 
address to redirect data and messages through the new set 

20 of interfaces. 
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A full range of queuing, communications and related 
services are accessible through EMS, but these can be 
selected and used only as needed. In each computing 
environment, the EMS API calls remain the same, so that no 
5 changes to the calls are required when migrating from one 
platform to another. The invention, moreover, supports 
most of the major wireless services, media and protocols 
as well as those on wireline networks, allowing developers 
to use EMS as a tool for integrating applications and pro- 
lOcesses that communicate across multiple networks. 

More specifically, EMS provides a single, consistent 
programmatic interface to access the queuing, communica- 
tion and related services for multiple external and 
internal communication networks, protocols and transport 
^facilities. Neither the user nor the application develop- 
er needs to be concerned with the specifics of various 
communi cations and network protocols and the characteris- 
tics of hardware devices. EMS, indeed, supports both 
wireline (dial-up, dedicated line, and LAN) and wireless 
20 ( radio frequency — RF and cellular) connection devices. 
These interfaces may be internal to the user organization 
or to public or private networks. Commun i ca t ion among 
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processes on the same computer are always supported. The 
communications interfaces, moreover, may be installed in 
any combination for which they are available in that 
environment, supported by the hardware and operating 
5 system, and providing a unique commtnon message switching 
application across this breadth of operating environ- 
ments. EMS automatically selects the proper communica- 
tions medium to use, although the user may override the 
default section. In either case, EMS takes care of all 

10 the message and network-level protocols on behalf of the 
user and/or application, providing transparent communica- 
tions selection and operation. 

As before stated, the invention handles both outgoing 
and incoming queuing of data or messages on behalf of the 

15 application or process. This means that the user does not 
have to wait for a communications mechanism or facility to 
become available to send data or messages. Similarly, 
data/messages can be received in background while this or 
other applications and processes are running. As appro- 

20 priate, both memory and disk queuing are supported to 
provide for automatic restart. 

EMS, furthermore, is configured at installation time 
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with various defaults. It may be reconfigured at any time 
without shutting down either the application or process or 
EMS itself. 

Referring to Fig. 1, EMS is shown installed in a 

5 simple system with two different environments I & II 
communicating across three separate network/protocol 
facilities 1, 1' and 1 M . The basic internal structure of 
EMS, interfacing multiple applications or processes, so 
labelled, and various communications facilities A,B and C, 

10 is shown comprising multi-media messaging, multi-network 
protocol, security services, full recovery, multi-plat- 
forms, directory services, guaranteed delivery, encryp- 
tion/decryption and compression functions, later more 
fully described. 

15 As previously mentioned, the EMS for each environment 

consists of a set of toolkit modules tailored specifically 
for that environment. As more particularly shown in Fig. 
2, the basic EMS modules are the following: 

Application Programming Interface labelled (API) - a 

20 get of single-function software modules, or verbs, that 
together provide a consistent interface through which 
application programs/processes can access the EMS communi- 
cations services. 
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Queue Manager/Router ( " Queues "/"Router") - stages 
messages and data flowing to and from the 

application/process and monitors the delivery status of 
each* 

5 Communication Agents ("Comm. Agent" or "CA") - one 

for each different network, protocol or communication 
transport facility, (shown as "Communication Network" "A" 
" B " & " C " ) . 

Communication Manager ("Comm. Manager" or "CM") - 
10 provides common messaging functions for all the communica- 
tions agent present. 

Configuration Manager ("Config. Mgr." or "CFM") - 
supports dynamic reconfiguration of EMS; automates the 
decisions for which communication medium and port to use 
15 and monitors availability of communications facilities. 

Configuration Utility ("Config.") - assists in soft- 
ware set-up and installation. 

User Status Utility ("USU") - allows the user to view 
queues and other status. User Configuration Utility 
("UCU") - allows user to manage available communications 
resources . 

Any number of nodes may be linked by communications net- 
works and facilities using the EMS of the invention. 
Considering, now, each of these modules in more 
25 detail, the application programming interface API, as 
before stated, consists of a set of verbs provided as 
callable routines for user programs. There are preferably 
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three basic verbs in the API corresponding to the three 
main functions required to handle message transfer and 
receipt : 

5 SEND 

RECEIVE 
COMMIT 

The function of the COMMIT verb is to finalize the message 
10 receive process once all segments of the message have been 
confirmed as received by the destination EMS* 
In addition, four message utility verbs are provided* to 
help manage messages and message queues: 

15 PURGE 
DELETE 
STATE 
STATUS. 

20 A final set of four environment utility verbs handle 

essential functions related to resource allocation and 
deallocation : 

INIT 

25 TERM 

GET BU F 
FREEBUF 

Together, these few verbs are able to provide a powerful, 
30 flexible and consistent programmatic interface across 
^\ multiple environments. 
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The Router of Figs. 2 and 4 is a background process 
which runs in support of API calls for data and message 
transmission, delivery and status, and as a server for the 
User Status Utility. The Router manages both disk-based 

5 and memory-based queues (for outgoing and incoming data/ 
messages) and sets event flags, depending on the environ- 
ment, to notify applications of message status changes. 
It also manages timed events for messages in progress, 
again depending upon the environment. 

10 0n startup, it rebuilds its queues from the disk- 

based save files. On shutdown, it stores messages which 
have not been completed and which have been designated as 
saveable to the disk save files. 

For incoming messages, if the application for the 
15 designated user is not active, the EMS Router may request 
the EMS Configuration Manager CMF to start the applica- 
tion process so that the incoming message can be deliver- 
ed . 

Each Communication Agent (CA), Fig. 2, is specific to 
the communications hardware and network to which it will 
attach and to the particular EMS operating environment. 
Each CA is structured in similar manner to handle the 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 951 1560A1_I_> 



WO 95/11560 



PCT/IB94/00322 



-20- 
line, RF device or other transport facility. On the EMS 
side, it passes messages to and from the Communications 
Manager (CM). Each CA, moreover, may operate as a driver 
or as an independent process, depending on the operating 

5 environment. 

As for the Communications Manager (CM), this comp- 
onent provides a set of common routines or independent 
processes used by all of the communication agents. The CM 
strips or adds any required control data for the environ- 

lOment to the received message (may contain network control 
data and message contents). The CM, furthermore, may be 
an independent process or a library (i.e. a Dynamic Link 
Library — DLL) depending on the environment in which EMS 
i s ins tailed . 

15 The User Configuration Utility (UCU) of Fig. 2 pro- 

vides an environmen t-specific process for the person main- 
taining EMS to install and maintain the various parameters 
EMS employs to manage the communication resources avail- 
able. UCU is run as a major part of the installation 

20 procedure to provide the initial defaults to the system. 
It may then be run on demand to up-date the defaults and 
to introduce new facilities and routing. 
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Lastly, Configuration Manager (CFM) is a background 
pr cess (or common library routines, depending on the 
platform) which runs in support of the Router, the User 
Status Utility (USU), and the User Configuration Utility 

5 (UCU). The CFM accesses configuration f ile(s) to determine 
service and communication agent to use for the delivery of 
a message, and other default parameters* It is also a 
server process for the environment-specific user utili- 
ties. The CFM, indeed, is the "start up" process for EMS, 

10 starting up all of the other background processes in the 
correct order, as well as the appropriate communication 
agents according to configuration defaults. 

It is next in order to examine the message flow 
through the EMS of the invention. Fig. 3 traces the raessa- 

15 ging process start-up and initialization, to the sending 
of the message, the checking of status, and the message 
receipt . 

EMS handles all communications between applications 
or processes using this me s s ag e- ba s ed datagram approach. 
^ u An EMS message, as before explained, may be a short text 
string, a large data file, or a megabyte or more of a 
multi-media message (text, data, graphics, images, voice 
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and even video) . Long messages are segmented by CMS at 
the destination. Segment length for an EMS message 
depends upon the network being used for transfer and is 
optimized accordingly. 

5 Each individual application creates its own message 

comprising any specific data-string, file, image, etc. as 
part of its normal processing, as shown at 2 in Fig,* 3. 
Editing and formating of message contents are done by the 
application or process strictly under its own control. 

10 When the application or process is read'y to transfer the 
data/message to an application or process on another 
computer (or on the same computer), it calls the EMS SEND 
service at 4. These calls are normally embedded in the 
appiica t ion/ proces s by developers and are not seen by 

15 application users except as the developer may wish to 

inform the user of this background activity. 

The EMS then formats the message for transfer. When 

the application or process calls the SEND verb, a message 

header, called the Interface Control Block (ICB), noted at 

20 4 in Fig. 3 and at 4' in Fig. 4, is built to identify: 
the ultimate destination of the message 
the tag for selecting this particular message 
the type of special processing required for the 
message 

25 # the urgency of the message 

the special handling characteristics of the message. 
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EMS then determines, as later explained, the proper 
medium and transport facility to use to reach the speci- 
fied destination, taking into consideration defaults set 
up in the configuration file for both the sender and the 
5 destination, the communication agents present, and the 
status of the various communication devices attached to 
the user computer. EMS then places the data/message queue 
and returns control to the application. 

When the designated transport facility becomes avail- 
10 able, the message is transferred and delivery confirmed. 

The data/message is transmitted by the Communication Agent 
CA, Figs. 2 and 4, associated with that facility and 
status of the EMS message is updated. If the message 
requires guaranteed delivery, then EMS will not consider 
15 it completed until a positive "commit" message is received 
from destination. The message is then delivered to the 
destination application. 

When a message is received by the destination through 
any of the communication agents, it is queued for receipt 

20 

by the destination application according to instructions 
in the later-described EMS message header, " EMH " in Fig. 
4. The destination application "asks" for each message 
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either automatically or as the result of a user command. 
Once the message has been successfully delivered to the 
destination application, EMS automatically generates a 
"commit" message back to the sending application (if re- 

5 quired by the sender). Message delivery is thereupon con- 
firmed to the sending application. When the sending copy 
of EMS receives the "commit" for a message* it automatic- 
ally releases the queuing resources taken up by the origi- 
nal message, and updates the status for the sending appli- 

10 cation, automatically freeing the message buffer. .Return- 
ing to the message processing chart of Fig. 3, and consid- 
ering the same in conjunction with the message header 
diagram of Fig. 4 (incorporating the system of earlier- 
described Fig. 2), the API routines or verbs, callable 
from the EMS literary structure that is native to the 
local computing and communications environment, enable the 
performance of the following functions. 

EMS is initialized at 5, Fig. 3, by calling the 
be f ore-lis tedlNIT verb which sets up sending and receiving 

2 ^ queues for the calling ap p 1 i ca t ion / pro ce s s and for each 
local communications transport facility (if these queues 
are not already in existence). Parameters used for 
initialization are retrieved from a configuration file but 
may be changed as part of the call. INIT must be called 
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by the application prior to issuing any of the other API 
verbs. 

Before building an outgoing message or requesting 
status, an application or process must obtain a memory 

5 allocation for the message control data and for the 

message itself by executing the GETBUF verb at 3, Fig. 3, 
Message control defaults are filled in by GETBUF but may 
be altered by the caller. GETBUF returns pointers to both 
the message control data and the message data area. 

10 Incoming EMS messages also require allocation of memory 
before they can be passed to the destination application 
or process. The EMS receive verb RECV (at 9, Fig. 3) 
automatically calls GETBUF in this case. 

To send a message, the application program or process 

15 executes the SEND verb at 4 after making any desired 
changes to the message control data and inserting the 
length of the data or message being transmitted. EMS 
checks the message control data as a header to the data/ 
message itself and places the combined structure, or EMS 

9 ft 

^ u message, on the EMS queue to await availability of the re- 
quired appropriate Communications Agent, CA , Figs. 2 and 

After the application has completed processing 
message or status response, it should release memory 
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allocated for the message control data and the message 
data areas associated with the EMS message. Memory for 
the message control data is freed by executing the FREEBUF 
verb at 11. After execution of FREEBUF, however, EMS is 

5 no longer aware of the message or able to access it. If 
the application needs to access the message later, the 
message must be saved by the application at 10. 

To receive an incoming message, the application or 
process executes the RECV verb at 9, Fig. 3. When RECV 

10 runs, the EMS Router, Figs. 2 and 4 , provides pointers to 
the message control data and to the data/message contents 
for RECV to return to the caller. One message at a time 
is given to the calling application or process. Following 
delivery of the data/message, its status in the EMS in the 

15 queue is updated. It should be noted that the message, 

together with its control data, remains on the queue until 
EMS receives a FREEBUF call (or COMMIT at 10) from the 
destination application or process. When an application 
or process which can receive messages starts up, it should 

20 immediately issue a RECV call to obtain any waiting 
incoming data/ messages. 

For most communications services and networks sup- 
ported by EMS, acknowledgment of received d a t a/ me s s age s is 
taken care of by the Communication Manager and Router, 
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Figs. 2 and 4, automatically on behalf of the destination 
application. For networks which support application and/ 
or user acknowledgments, however, the application program 
must call COMMIT (at 10, Fig. 3) to send the back through 

5 the network originator. 

Applications and processes can obtain the status of 
an EMS message by executing the STATUS verb at 6-8, Fig. 
3. Message status is maintained by EMS in the message 
control data area of each EMS message stored on the 

10 queue s . 

Applications or processes can find out the state of 
an EMS queue by executing the STATE verb. A STATE query 
for a queue returns the number of active items in that 
queue, and the state of the queue. Individual EMS raes- 

15 sages, moreover, may be deleted from the EMS queue by 

invoking the earlier listed DELETE verb. All items in a 
queue destined for the same address may be deleted with a 
single DELETE call. Items designated are deleted regard- 
less of status. If outstanding acknowledgements are 

20 received subsequently, the application or process will be 
notified. The DELETE verb is not used in normal process- 
ing. It should be invoked with care only to cancel 
messages which have not been sent because of extended 
unavailability of destination systems or communications 

25 links. 
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All items in an application or process queue (either 
incoming or outgoing) may be discarded by calling the 
PURGE verb. The purge action takes place regardless of 
the status of individual messages. The PURGE verb is not 
5 used in normal processing.. It should be invoked with care 
and only in error correction situations, (See DELETE.) 
Before an application or process using EMS ends, it 
normally calls the before-mentioned EMS API termination 
verb, TERM . TERM "cleans up" all outstanding messages 
10 (incoming and outgoing) for the calling application or 
process, ensuring that the messages to be saved are 
properly stored on disk. This includes both application/ 
process created data/messages and EMS administrative or 
commit messages. If the EMS queues for the application/ 
15 process are empty, they are deleted. (They will be 

created again when the application or process starts up or 
a message is received for the application/ process, Fig. 
3.) 

In accordance with the invention, EMS encapsulates 
20 each message submitted by an application (via the EMS API) 
for transport across whatever network/ protocols EMS is 
configured to support. Encapsulation involves completing 
an EMS Message Header ( EMU ) , Fig. 4, for the message data 
prior to transport and removing the transport specifics 
25 from EMH just before delivering the message data to the 
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destination application. This header contains all inform- 
ation necessary for EMS to transfer the message from the 
originating application and EMS copy to receiving EMS copy 
and destination application across whatever network/ 
protocol combination that may be required, as schematic- 
ally shown in Fig. 5. 

The EMH is used internally by EMS, as well as by 
certain networks, to instruct the various processes 
involved in transfer as to how the message is to be 
handled, and its format asnd content may change several 
times as it moves through the sending EMS, communications 
ne t wo r ks / p ro t oco Is and the receiving EMS. Certain fields 
are dropped when no longer needed; others are compressed 
or coded to minimize overhead; fields generated within EMS 
are added for temporary use by certain networks and 
protocols are removed immediately after they have served 
this purpose . 

The full EMH is also structured according to the 
message class-of-service; i.e. the message priority, 
length and requested acknowledgement level. These para- 
meters are used by EMS to determine the path that the 
message will take (including communications service(s) 
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selection), with the EMH containing only the minimum 
amount of information needed to support that class-of- 
service. The EMH for any specific message thus represents 
a specific clas s - o f - s e r v i ce view of the full EMH - one 
5 that may have both different content and different format 
depending on the handling characteristics, processing 
stage and communications medium. 

In Fig. 4, EMH transformations at the various stages 
of EMS are shown. The programmer will be concerned only 
10 with the fields that specify message handling and end - to 
- end logical addressing in the Interface Control Block. 
(ICB) portion 4* of the EMH . All other fields in the EMH 
are handled internally by EMS. 

EMS messages can be of any length (subject to 
15 constraints of the local operating environment) but most 
networks and protocols have some limitations on message 
length. This means that EMS must provide some mechanism 
for subdividing messages that are too long for the 
specified communications path and for reassembling the 
20 pieces at the destination. In practice, message' sub- 
division may be done in several steps. First, message 
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segmentation. Messages no longer than some nominal limit 
- usually 32,767 bytes - are segmented upon receipt by EMS 
prior to being enqueued for transmission* This nominal 
limit is contained in the EMS configuration files and is 
also modifiable. Secondly, segment packetization . Most 
networks and protocols have a maximum length for actual 
transport (and error correction) and for handling of the 
transported data internally. Since each protocol has 
different framing requirements, the EMS software or local 
operating environment must take care of this final 
subdivision and formatting. A packet may require several 
frames to transport In full and receiving component of EMS 
(or local operating environment) must handle reassembly of 
frames into packets. This subdivision and reassembly 
process is transparent to applications and processes that 
use EMS. EMS , indeed, hides all of the message handling 
and communications complexity from users and their 
applications, removing this costly and burdensome task 
from users. 

The details of developing outgoing messasges are 
presented in the flow chart of Fig. 6 which outlines the 
main steps in preparing a message for transmission and in 
sending that message. 
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The application, through its normal processing, 
creates at 20 the block of data to be transferred. This 
data block or message MD , as previously explained, may 
have a simple structure such as text, or it may have a 
5 complex internal structure containing binary data, images, 
text, graphics and other objects that have meaning only to 
the receiving application. EMS has the job of delivering 
this message content to a specified destination without 
loss* 

10 The application (or its user) must also decide at 21 

how the message MD is to be handled (this defines the 
class-of-service for the message). Handling options 
supported by EMS may include acknowledgement level, prior- 
ity with regard to other traffic, service routing accord- 

15 ing to logical destination, identifier, recoverabili ty , 
retry options, and timing and delayed delivery options. 

The message destination must be specified using IDs 
(7, Fig. 3) that have been established for the user envir- 
onments. Both message handling and message destination 

20 specifications are loaded into a special EMS data buffer - 
the Interface Control Block (ICB) 4', Figs. A and 6, - 
before the EMS API function call is made. 
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After defining both the message data content for EMS 
(in terras of length and pointer to message data start) and 
the message handling instructions (via the ICB), the appl- 
ication makes calls to the EMS API to make the transfer* 

5 In general, this requires a GETBUF call (3,6 in Fig. 3) to 
set up the message resources, and a SEND call ( 4 , Fig. 3) 
to initiate the transmission (depending on the platform). 
The receiving EMS process is the EMS Router, Fig. 6, or 
Queue Manager "QUEUES" , depending again on the platform 

10 involved . 

Upon receipt of a message MD , EMS "encapsulates" it 
by prefixing the message handling data as a message header 
at 22 to the message data to form the complete EMS message 
ready for transport. As described before, content, struc- 

1^ ture and format of data in this header changes as the EMS 
message moves through the process. Because, as previously 
explained, EMS is designed to handle messages of any 
length, longer messages (such as images) must be broken 
into segments of the maximum size supported jointly by the 

20 networks involved, as at 24. In practice, this may be f 
for example, a 10,000 byte or 32,767 byte size limit so 
that megabyte-size messages must be broken into many seg- 
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raents. Each segment carries an EMS header and is treated 
as an independent datagram between the source and destina- 
tion EMS copies, being stored for transport at 25. The 
EMS-gener ated message segments will often require further 

5 subdivision, as before detail ed, to accomodate network and 
protocol requirements- The appropriate communication 
agent is selected at 28, and for actual transport across 
many networks, messages are broken into the before - des- 
cribed packets of specific length and structure at 26. 

10 Error detection fields may be added during the pacfeetiza- 
tion process. 

The message packets created by EMS normally undergo a 
further subdivision into frames at 27, for actual trans- 
port. The communication device (modem, port, driver, 

15 etc.) and the underlying network layer handle transport at 
30 of data frames from a source node to a destination 
node, often by way of a number of intermediate nodes. 
Error detection and frame retransmission where errors are 
detected occur at this level. Since EMS ships only the 

20 header data needed by the receiving EMS to Handle the 

message properly, all other header information is stripped 
prior to transport. Message header data required by cer- 
tain networks and services are added to the EMS message 
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header in positions, structures and formats required by 
these such specialized header data is also removed when no 
longer required. 

It is now appropriate to consider, in detail, the 
5 treatment of the incoming messages sent by the technique 
of Fig. 6. The principal steps involved in receipt of a 
message to the destination application are shown in Fig. 
7 . 

The message data, and frame format, are received at 
10 31 at each EMS - supported node and are reassembled' into 
packets at 32. The transport layer data and structures 
are removed and the message header is unpacked to its full 
EMS format. The message packets are reassembled at 33 
(segmentation created by the sending EMS is removed) and 
15 protocol data stripped and local header data added at 34. 
The segments are delivered to the local EMS QUEUE or 
Router at 35, where the complete messages are reassembled 
at 36 and acknowledgment messages generated, if needed, at 
37. On this queue, messages await either delivery at 38 

2 0 

to a local recipient or transmission over the next trans- 
port hop. When the destination application or user re- 
quests a message from its assigned EMS Queue, using the 
RECEIVE verb, the message storage area Is delivered to the 
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application. Other data contained in the message ICB is 
also available to the application, if needed. The appli- 
cation can read the message data and display it or store 
it for the intended user (or application). If the ICB 

5 specifies that application or user acknowledgement is 
required, the receiving application must initiate an 
appropriate acknowledgement at 4 0 . Formal return receipts 
are transmitted to the message sender as separate 
messages. Acknowledgement of receipt internal to EMS is 

IQ handled by the COMMIT mechanism and does not involve 

either sending or receiving application. EMS generates 
the properly formatted messages on behalf of the applica- 
tion . 

Messages requiring any processing following delivery 
15 to the destination must be processed by the destination 

application or by an associated module. This responsibil- 
ity includes saving of messages as at 41 (and of the ICB 
if neccessary). EMS releases all resources involved in 
message transfer as soon as the receiving application 
20 notifies EMS (using the before-described FREEBUF verb or 
COMMIT verb) that it no longer needs separate access to 
the me s s age . 
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Some important implementation details of routing 
functions for outgoing message handling and other func- 
tions will now be addressed. Look up destination routing 
options may be used, providing possible media and network 

5 addresses for the destination (using an address book func- 
tion) based upon the ICB contents. Such an EMS address- 
book may contain a short name by which the user knows the 
correspondent, the correspondent's expanded name, the 
correspondent's location or address (description field), 

10 the correspondent's city, networks and their associated 
addresses for the correspondent, routing preferences for 
this correspondent, owning user or public indicator, 
compression option, encryption key to correspondent, 
encryption key from correspondent, and the like, 

15 Message size and the other class-of-service charac- 

teristics are evaluated to determine which communication 
network provides the best route to use for the next hop. 
This information may be contained in the general routing 
configuration file having, as contents, maximum message 

20 lengths -- i.e. 100, 200, 1000, 2000, 10000, 999999 

and, by priority, text type (character, binary), and maxi- 
mum message length. 

It is also important to provide for the extraction of 
new network message information. If the outgoing message 
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is to transverse a processing network (for example, the 
Motorola MoNet) and the network ID for the destination is 
not in the addressbook, then it is added to the address- 
book. Like all of the other configuration files, the 

5 addressbook itself is an editable file and may be 

completed with other information at a later date. The ID 
is captured on the fly, however, to simplify later raain- 
tai nence by the user or administrator* 

To complete the EMS message header, proper network, 

10 communication medium, next hop and final address (as 

appropria t e ) are filled into the ICB and reformatted as 
needed into the EMS Message Header (EMH), Fig. 4. Only 
the next hop and final address (as known) are inserted. 
Each hop along the way determines the medium and address- 

15 ing for the next hop. This approach means that pathing 
may vary as necessary and achieves the desireable result 
that such is totally transparent both to the preceding and 
succeeding hops and to the initiator and receiver of the 
me s sage. 

20 Based on the communication medium selected, moreover, 

the proper communication agent type is selected from the 
service information file. For each EMS Communication 
Agent type, a standard template is provided including 
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service name, process driver name, CA class (Express, 
Bulk, All), type (i.e. ARDIS), device ID (ESN or telephone 
number), port or network address, start automatically at 
run time (Y/N), shut down when no applications open (Y/N) 

5 (i.e. last TERM), maximum message size (including ICB's 

but not protocol headers), block/packet size, name, of file 
containing startup command for communications agent, and 
name of special parameter file (for device/network 
specific parameters), This is where all of the protocol 

10 and device specific information goes and it also uses the 
keyword formats. 

The message is segmented to the maximum message size 
from the relevant service file entry.as earlier discussed, 
and the messages are placed on the queue defined by the 

15 service. This is "receive" queue for the appropriate EMS 
Communication Agents. Depending on the platform, the EMS 
Router notifies the Communication Manager that there is 
traffic to be sent out on this queue* 

Another function for processing outgoing messages is 

20 deferred sending, as where the queue management software 

will delay passing the message to the communications mana- 
ger until the specified time is reached. If the next hop 
routing for a message cannot be completely determined, 
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furthermore , the reason for the problem is placed in the 
ICB return code field. The message is they placed either 
on the application "receive" queue or the "receive queue" 
for the application specified as the error process in the 

5 EMS header. The application selection is determined from 
the information in the local message header defaults 
configuration file, and the queue is selected from the 
application configuration file. 

Further details on the handling functions of the in- 

10 coming messages are similarly helpful. For identification 
of the destination queue, the receiving EMS uses the 
application and destination ID in the ICB attached as part 
of the EMS Header, Figs. 3 and 4, to determine, the proper 
queue for the message. The queue name is selected from 

15 the application configuration file, if it is present, 

including such items as application or process name, Queue 
name, maximum number of copies (as applicable), start flag 
— if not running when incoming messages received (Y/N), 
pass incoming commits to application (Y/N), pass incoming 

20 network acknowledgments to application (Y/N) , permanent 
queue flag (Y/N), queue by user and application (Y/N) — 
vs. by application only, outgoing queue size (initializa- 
tion), incoming queue size (initialization), startup file 
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name (for complete startup command to start process), and 
text type of message generated (character, binary), etc. 

If no application is specified in the incoming mes- 
sage, then the default application for the destination 

5 user is selected from the user configuration file. If 
there is no default application, the message is enqueued 
only for the user. The received ICB and header is expand- 
ed and checked td^ see If a commit and/or other acknowledg- 
ment is required. If the routing functions are to gener- 

10 ate these messages automatically before the application 

receives the message, then the appropriate header informa- 
tion is extracted for use In these datagrams. Depending 
on the platform, moreover, the routing process will detect 
true duplicates. These duplicates are identified by the 

15 same message ID (which includes segment number)- In these 
rare cases, the second message is considered the duplicate 
and is discarded since the message database is keyed on 
me s sage ID . 

The message status is set to "received but not yet 
20 retrieved from the queue", and the message is enqueued on 
the "receive" queue for the application* Routing func- 
tions determine if a commit or device— level acknowledgment 
is required for the incoming message from the ICB con- 
tents. The commit requirement is determined by the set- 
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ting of the receipt requested field In the internal por- 
tion of the ICB while device acknowledgement requirement 
is determined from the confirmation mode field in the net- 
work portion of the ICB. The commit and/or acknowledgment 

5 is not generated until the message is enqueued for the 

destination application or next hop. This meets the "safe 
storage" requirement of many mi s s i on c r i t i c a 1 applications. 

As in the case of the outgoing message handling, as 
above explained, if a message is received via a processing 

10 network and the sender's network ID is not in the 'local 
addressbook, then it is automatically added. Like all of 
the other configuration files, the addressbook is an edit- 
able file and may be completed with other information at a 
later date. The ID is again captured on the fly, however, 

15 to simplify 1 a t e r raa i n t a i ne nee by the user or administra- 
tor. 

Successful receipt of a message (segment) by a final 
destination or delivery service is signalled by an acknow- 
ledgement message being returned to the sender. There are 
20 a t least four levels at which the ability to generate 

receipt acknowledgements are valuable; namely, user (i.e., 
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a person), application, device (EMS) and/or communication 
protocol. EMS handles device and protocol acknowledge- 
ments and, through its API, support a p p 1 i ca t i o n- 1 e ve 1 and 
user-level acknowledgements if the application developer 
5 elects to provide these. All EMS messages have "network- 
level" fields to define these important class-of-service 
options. 

Considering the above-mentioned device acknowledge- 
ment, an EMS Router that receives a message (segment) will 

10 generate a "device acknowledgement" if required and will 
forward it as a seperate datagram back to the message 
originator via the same path. A device acknowledgement is 
required if the confirmation mode in the ne t wo r k- r e 1 a t ed 
fields in the EMS message Header is set to "device acknow- 

15 ledgement . " For example, when the Router at the destina- 
tion subscriber unit receives an incoming message via a 
processing service (e.g., MoNet) which has the confirma- 
tion mode in the network 1CB set to "device acknowledge- 
ment", the Router will generate. the required device ac- 

20 knowledgemen t message and forward it as a separate data- 
gram back to the message originator via the same process- 
ing service path. An example of the content of such a 
device acknowledgement is presented in the following Table 
1 : 
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15 



20 



25 



Tnblc 1. EMS Message Header: 

DEVICE ACKNOWLEDGEMENT - Local ICB Portion 


Field 


Content 






Eye Catcher 


'CACB* 


Release 


'0300* 


Message Pointer 


Default 


Message Length 


22 


Netwoik ICB Pointer 


Default 


Network ICQ Length 


Default 


Destination Fields 


Source fields from incoming message 


Message ID 


Hew ID for Hie acknowledgement 


Number of Segments 


1 


Mode 


Express 


Hop Format 


"B* 


Local Priority 


-0" 


Recovery 


r 


Commit Indicator 


*Y" 


Commit Type 


'2' 


Commit Sotirce 


Destination address from incoming message 


Original Message ID 


Message If) frum incoming message 


Number of Retries 


Default 


Retry Count 


Default 


Interval 


Default 


Retransmission 




WOIES 
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A destination application may be given the ability to 
generate an application acknowledgement to confirm the 
message receipt by having the application issue a COMMIT 
call to the destination EMS Router* The EMS Router will 

5 generate the required application acknowledgement message 
and Forward it as a separate datagram back to the message 
originator via the same network path* When the destina- 
tion application issues a COMMIT verb for a message marked 
for "application acknowledgement" in the confirmation 

10 field, the Router will generate the required application 

acknowledgement message and forward it as a separate data- 
gram back to the message originator via the same process- 
ing service path. A typical application acknowledgement 
content is shown in the following Table 2: 
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5 



20 



TaWn 2. EMS Message Header: 

APPLICATION ACKNOWLEDGEMENT - Local ICB Portion 


field 


Content 






Eye Catcher 




nutcase 




Message? i OiriiGf 




Message Length 


22 


Nehrorx ICB Pointer 


uerauit 


NetwoiK iou Lengtn 


rVnt^f til 

uerauit 


f"^A#*l*r***linrt £T Lit ^ 

ucsiiiiRuon rieios 


ouuiwj iiciub ii mil iimuiiuii^ niussdyu 


Message iu 


new iu lor uic ncKiiov/ieogement 


Number of Segments 


* 

i 


Mode 


Express 


Hop Fonnat 




Local Priority 


*o* 


Recovery 


T 


Commit Indicator 


*Y* 


Commit Type 


'T 


Commit Source 


Destination address from incoming message 


Original Message ID 


Message ID fiom incoming message 


Number oF Retries 


Default 


Retry Count 


Default 


interval 


Default 


Retransmission 


■o* 


NOrES 
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A destination application may also be given the 
ability to generate an acknowledgement confirming message 
receipt by the receiving user. This requires the applica- 
tion to issue a COMMIT to the destination EMS Router. The 

5 EMS Router will generate the required acknowledgement 

message and again forward it as a separate datagram back 
to the message originator via the same network path. 
When the destination application issues a COMMIT verb for 
a message marked for "user acknowledgement" in the con- 

10 firmation mode field, the Router will generate the re- 
quired user acknowledgement message and forward it as a 
separate datagram back to the message originator via the 
same processing service path. 

A typical user, acknowledgement content is shown in 

15 the following Table 3: 
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10 



Table 3. EMS Message Header: 

USEn ACKNOWLEDGEMENT - Locsl ICB Portion 


Held 


Content 






Eye Catcher 


"CACB- 


Release 


•0300* 


Message Pointer 


Default 


Message Length 


30 


Network ICB Pointer 


Default 


Network ICB Length 


Default 


Destination Fields 


Source fields from iiraming message 


Message ID 


New ID for the acknowledgement 


Number of Segments 


1 


Mode 


Express 


Hop Format 


"B" 


Local Priority 


'0* 


Recovery 


T" 


Commit Indicator 


T 


Commit Type 


"2" 


Commit Source 


Destination address from incoming message 


Original Message 10 


Message ID Irom incoming message 


Number of-Retries 


Default 


Retry Count 


Default 


Interval 


Default 


Retransmission 


*0" 


WCTTES; 
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When the EMS Router receives a network acknowledgment 
message, It uses several fields in the network portion of 
the EMH to match the acknowledgment to the original out- 
going message : 

5 

Message ID 

Me ssage Tag 

Application 

Des tinat ion/ Sour ce ID 

10 

Only one level of acknowledgement is received for a 
message. A message with multiple destinations (list) how- 
ever will get the same acknowledgement type from each 
destinattion which successfully receives the message. If 

15 at least one acknowledgement is received, then it is up to 
the processing network to deliver the rest. Since the 
expansion of group addresses may take place at the pro- 
cessing network, the source has no way of knowing how many 
acknowledgements will be received. In this case, the con- 

20 figuration for this application should be set to return 
acknowledgments to the application for final reconcilia- 
tion. If, therefore, a network - generated acknowledgment 
is received for a message which is not on the EMS Router's 
queues, then the acknowledgment is placed on "receive" 

25 queue for the originating. user (from the source network 
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ID field in the network-related EMH fields) and 
application . 

In the event that a message cannot be delivered as 
specified in the EMH, a negative acknowledgment in the 

5 confirmation mode field is generated if so requested by 
the processing network. Gateways in a network complex, 
furthermore, even if they are EMS - s up po r t e d , simply pass 
through acknowledgment messages in the same manner as for 
any other message (except in the rare case that the Gate- 

10 way node itself is the destination). 

While earlier referred to, it is now in order to 
explain the details of the EMS Message Commits. The 
commit, it will be recalled, is an internal message sent 
from a receiving EMS to the sending EMS to notify the 

15 sender that the message at the sending side may be 

released* This is the mechanism by which EMS is able to 
guarantee delivery and to recover messages in the event of 
any transmission lo.ss. 

The EMS router issues a commit message to the EMS 

20 Communication Manager upon receipt of a message requiring 
a receipt acknowledgment. The commit is issued after the 
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EMS Router has placed the message safely on the queue for 
the next destination* This commit, Fig. 3, is passed as 
an independent datagram (i.e. EMS message) through the EMS 
Communication Agent back to the previous sending computer 

5 EMS Router, serving as acknowledgments bet we en the hops. 

Typical content of the EMS Message Header in a commit 
datagram is shown in Table 4. (All other fields are set 
to default values.) Commits are not retriable messages, 
such that if they fail, then the normal message recovery 

10 will take over . 
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5 



Table 4. EMS Messngc Header: 


COMMIT 




frftfrt He/a 


Content 






eye unTcner 




□ ntnMnn 

Heiease 




Message Poinff*r 


n 


Message Lenglh 






n 


MoKt/nrif Arni 1 onnlrt 


n 

u 




^rurrro finlrlc n rvn irvnminn mneennp 


Mpccnnp ID 

rile S jOyc 1 L/ 


New IU For Hip. commit 




| 




Express 


Linn Cnrtn^l 

nop rormni 


-p* 


1 nril PtinnKi 

LOCcjt i noncy 


*n* 

u 


Recovery 


-y. 


Commit Indicator 




Commit Type 


*r 


Commit Source 


Destination address fiom incoming message 


Original. Message ID 


Message ID from incoming message 


Number ol Rf?tr»e?» 


0 


Retry Coimt 


0 


Interval 


0 


Retransmission 


*rr 





SUBSTITUTE SHEET (RULE 26) 

BNSDOCID; <WO 9511560A1 J_> 



WO 95/11560 



PCT/TB94/00322 



-53- 



Considering now the handling of an incoming EMS 
Commit, when the EMS Router receives a commit from the 
next hop destination, it updates the status of the next 
message in the QEB for the message segment, and determines 
5 if the original message is now complete. If the message 
has an EMH destination node, which implies a network, then 
the EMS Router has to wait for acknowledgments as directed 
in the net work- related EMH fields before marking the 
message as completed. If the message is complete, the EMS 

10 Router removes the related message from its queues or 

enqueues the original message and/or commit as directed by 
the exit routine area in the EMH. If, however, the message 
is not complete, the EMS Router leaves the message 
enqueued as it was, but with the new status, on the EMS 

15 Communication Agent queue (which is part of the Router 
queue). Finally, if a commit is received for a message 
which cannot be found by the EMS Router, it discards the 
commit. (the original message may have expired, or may 
have been deleted by an application) . Upon the lapse of the 

20 time periods specific in the EMH (or ICB) interval field 
before a commit message is received from the next hop, 
then a retry sequence Is initiated. 
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It is next appropriate to consider the actual 
integration of the invention EMS into applications and 
processes — such involving little more than inserting 
calls to the EMS API verbs at appropriate points in the 

5 programs. Before each call , of course, the fields 

required by the verb must be loaded by the application. 

In some situations, there will be nothing more 
required in terms of interface design. EMS functionality 
will provide everything needed to handle the application 

10 requirements. More commonly, however, the application or 
process will need to have a number of interface routines 
added to handle tasks such as saving messages for future 
reference, notifying users that messages are waiting, 
handling addressbook ma i n t a i nence , creating application/ 

15 process acknowledgments, creating user acknowledgements, 
and the like. The principal aspects of setting up calls 
to the EMS API involve only loading the interface control 
block (ICB), Fig. 4, that accompanies each message 
content . 

20 As will be recalled, message handling instructions 

from the sending application/user are placed by the appli- 
cation into the special EMS data buffer called the Inter- 
face Control Block (ICB). Applications must provide 
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certain pieces of the ICB data before calling the EMS API 
to begin message transfer. EMS loads default data into 
the message ICB prior to allowing the application access 
to the ICB. The message ICB, indeed, exists only for the 
5 purpose of communicating between application and the EMS 
API. Data in the message ICB becomes the EMS Message 
Header once the message is accepted by EMS for transfer- 
Application programmers are given access to the external 
10 view of the ICB f divided into two major portions: Data 

that governs end-to-end communication and most class-of- 
service processing; and data that determines local proces- 
sing for the communications hop in progress. Information 
is not duplicated from one portion to the other. 

15 

EMS, in accordance with the invention, manages both 
the end-to-end communications as well as each Intermediate 
hop. The application never sees the details of the 
intermediate hop and it has no need ever to know this any 
20 more than one would care how a telephone call was 
physically routed. 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 951 1560A1_I_> 



WO 95/11560 



-56- 



PCT/TB94/00322 



When the application executes the GET BUFFER verb 
Fig. 3, EMS hands back an initialized external view of the 
ICB along with the message area and destination list 
area- Both the network and local processing portions are 
5 set to the default values, along with the addresses and 
lengths determined for the GET BUFFER call. 

While the only network which currently utilizes the 
network fields in the ICB directly is the Motorola MoNet, 
the information in this area is sufficient to permit 
10 connection to many other processing networks with the 

addition of a new communication agent. Layout of the ICB 
is independent of the actual communications media and 
networks used in the message transfer. 

The ICB is accessed as a structure by the 
15 application. In order to guarantee compatibility with 

future EMS releases, the application should always access 
the ICB fields by name within the s t r u c t ur e . T he ICB 
structure is provided to the application programmer as a 
•c f header file. ItiRTREXT.H. If the calling program is 
20 not written in 'c* than a similar structure needs to be 
defined In the development language. 
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This header file includes both the structure and the 
definitions of the layouts of various internal fields. 
The application may use these internal field definitions 
elsewhere for other purposes so that the programmer should 
5 always address the subfields by name to preserve compata- 
bility with later releases. If the programmer saves the 
ICB or portions thereof to structured disk files (depend 
ent on the platform), a file conversion may be necessary 
to access this data between EMS versions. 

10 In the ICB layout, network fields are presented 

before the local processing fields. Field defaults are 
taken from the configuration files NETYICB and LOCALICB. 
In Tables 1-4, the fields that are presented and addition- 
al regained fields have the following descriptions. 

15 Eye Catcher 

The eye catcher field is filled in the EMS API verb GET 
BUFFER and is used to ensure that the processing computer 
recognizes the header area. It is two byte character 
20 field * and ls 6et to '*<?*" in this version of EMS, The 
initial value comes from the METICB configuration file. 
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Release 



The release field is filled in by the EMS API verb GET 
BUFFER and is used to ensure that the processing computer 
5 is utilizing the correct view of the 1CB for the EMS 

version which initiated the message* The initial value 
comes from the NET I CB configuration file. 



Message Length 

10 

The message length contains the length requested by the 
application in the call to EMS API verb GET BUFFER. It is 
an unsigned short integer, limiting message length to 
32,767 in this example. There is no default message 
15 length. 



Mes sage Type 

The message type currently defines the administrative 
20 message type according to, for example, the before - 

mentioned Motorola MoNet Service standards. The default 
value is "MS" for a normal' message and is taken from the 
NET1CB configuration file. This is a two character 
field* The application should normally produce only: 
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Message (MS), MN (parameter maintainence) t Status request 
(ST) and Look-up (LU) types. Depending on the setup of 
the configuration files, the application should expect t o 
receive only: Message (MS), Look-Up Response (LU). 
5 Maintainence Response (MN), and Status Response (SR) 
types • 

EMS configuration files, as before discussed, may b« 
set up to return acknowledgements to the application, in 
which case the Services Acknowledgement (DL), the Device 
10 Acknowledgement (DV) t the Application Acknowledgement 
(AP), the User Acknowledgement (US), and the Negative 
Acknowledgement (NK) message types. This field is used In 
determining the ultimate class-of -se r vi ce . 

15 Text Type 

The text type indicates whether the contents in the 
message area are to be considered as binary or text, for 
compression purposes. Other values may be added further 
to describe the types of objects which may be shipped via 
20 EMS. This field is set to binary always, at this time, 
and the default is always taken from the NET I CB configu- 
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uration file. This field is presented to the application 
to ensure that It moves data properly internally. Text 



the ultimate class-of-services. 

5 

Delivery Mode 

The delivery mode is used by the processing network to 
define retry policy for messages to be routed by the net- 
10 work. As illustrations, "send once and quit", means that 
the message will be sent to the delivering service once. 
The processing network then discards the original raes- 



means that the message will be retried on a periodic basis 
15 until the proper acknowledgement message is received in 
response or until the message reaches its expiration 
time. The acknowledgement level is defined in the confir- 
mation mode field. The default for this field is set from 
the NET I CB configuration file. This field is Ignored, 
20 however, for messages in which the processing network 

generates a corresponding response and is used in deter- 
mining class-of-service. 



type is a one-character field and is 



used in determining 



sage. The confirmation is ignored. 



Send until expired" 
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Delivery Expiration Time 

The delivery expiration time is used by both the 
processing network and local EMS copy to determine when a 
message should no longer be kept in an incomplete state. 

5 

It is expressed in minutes as an unsigned integer and the 
default is taken from the NET I CB configuration file. 
Maximum value, for example, is 32767 minutes (approximate- 
ly 22 days)* 

20 Confirmation Mode 

The confirmation mode defines the level of acknowledgement 
which the application expects in response to the receipt 
of the outgoing message by the ultimate destination. This 

15 is a one-character field and the default is set from the 
NET I C B configuration file. The administrator, further- 
more, may want to set this to other than supplied value 
depending on the criticalllty of the applications which 
will be using EMS to send messages from this platform. 

20 This field is ignored for messages in which the processing 
network generates a corresponding response. This field is 
also used in determining class of service. 
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Rncryption Mode 

The encryption mode defines the type of encryption and 
compression processing to be applied to the message area. 
The default value for this one-character field is also 
taken from the NET 1 CB configuration file. This field is 
further uaed in determining c 1 a s s -o f - s e r v i c e . 



Destination List Type 

10 

The destination list type is a one-character field that 
identifies the types of identifiers provided in the 
destination list. The processing network uses this 
indicator further to determine class-of-service . The 
15 default value once more is taken from the NET I C B 

configuration file. The value of destination list type is 
compared against the destination list actually provided 
(single entry or multiple) for consistency when the 
sending application executes the EMS API SEND verb. 



20 



Routing Preference 

The routing preference is a one-character field which the 
processing network uses to determine how best to reach the 
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final destination, with the default value taken from the 
NET ICB field. The administrator of EMS on this platform 
may want to alter this default, depending on the 
criticallity of the application on the platform. It 
should be noted that a message to a single destination ID 
can be expanded by the processing network to multiple 
messages. This implies that multiple acknowledgements may 
be returned. This field is used in determining the 
ultimate class-of-service. 

Message Priority 



The message priority determines the order that this 
message will be handled by EMS and the processing network 

15 relative to other messages. The value of this 

one-character field varies form the number "0** to "9", 
with "0" being the highest priority. The application 
should send messages with values "I" through "9" only, 
since commits and some network responses use "0" to ensure 

20 the speediest processing possible. The default for this 
field is contained in NET I C B configuration file. This 
field is used in determining class-of-service by both EMS 
and the processing network. 
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Recovery 

The recovery indicator is used by EMS on certain platforms 
to indicate whether the message is to be put to permanent 

5 media while it is active. Certain platforms always put 

messages to disk while the message is active. Others keep 
active messages in memory only, unless directed by this 
field to put them to disk. If the recovery indicator is 
set to M N ** , then the message may be lost by an EMS copy if 

10 the platform fails while the message is in an active 
state* Possible values may be " N " for no and "Y" for 
yes. The default value once more is taken from the NETICB 
configuration file. 

15 Destination Node 

The destination node name identifies the name for the next 
hop. This field ne^d not be used by the sending 
application if the destination list type is single and the 
20 destination ID is present in the addressbook. It is 

filled in by the routing logic in response to the EMS API 
SEND verb or if the default from the NETICB file is 
sufficient* It is provided for information purposes to 
the receiving application at the destination EMS 
installation, and reflects the last hop information. 
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Destination Service 

The destination service identifies the communications 
medium (communication agent type) over which the message 

5 is to be sent (outgoing) or was received (incoming) for 

the current hop. This field need not he used by the send- 
ing application if the destination list type is single nnd 
the destination ID is present in the addressbook. It is 
filled in by the routing logic In response to the EMS API 

10 SEND verb or if the default from the NET I CB file is suffi- 
cient. It is provided for information purposes to the 
receiving application at the destination EMS installation, 
and reflects the last hop information. Possible values 
for this two character field depend upon the communication 

15 agent set installed on the platform. 

Destination Address 

Destination address is the specific network address (i.e. 
20 telephone number, radio modem ID t IP address, x.25 

address, etc.) by which the message is to be delivered to 
the next hop (outgoing) or by which the message was 
received (Incoming). It is filled in by routing logic in 
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response to the EMS API SEND verb of if the default from 
the NET I CB file is sufficient. It is also provided for 
information purposes to the receiving application at the 
destination EMS installation, and reflects the last hop 
5 information. This is a 16-character field and presents 
the address in its expanded format. 

Network Source User ID 

10 If the EMS installation on a platform supports an inter- 
face to a processing network, then the network ID of the 
current user is placed in this eight-character field. It 
is provided to the application for reference only. 

15 Submitting Network 

For outgoing messages, this Is the communication medium 
which will be used to send the message to the first hop. 
Possible values for this field depend upon both the 
20 communications media which are installed on tit is platform 
and those which can somehow connect with a processing net- 
work. This field is filled in by routing logic in 
response to the EMS API SEND verb or is the default from 
the NET ICB file, if sufficient. 
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Submit ting Device 

For outgoing messages, this is the communication network 
address (i.e. telephone number, radio modem ID, etc.) 

5 which will be used to send the message to the first hop. 
For incoming messages, this is the communication network 
address over which the message was sent to the first hop. 
Possible types and formats for this field depend upon both 
the communications media which are installed on this plat- 

10 form, and those which can somehow connect with a process- 
ing network. Contents of this field may be compressed if 
the address is numeric and can be longer than eight 
numeric characters. This field is filled in by routing 
logic in response to the EMS API SEND verb or is the 

15 default from the NET I CB file, if sufficient. 

Message Pointer 

The message pointer is provided in response to the EMS API 
20 verb. It is a pointer to the message data area which is 
as long as the message length. The application must not 
change this value but needs to use it to fill in the 
message contents or to retrieve the message contents, as 
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is appropriate. The format of the pointer is platform- 
dependent . 



Address List Pointer 

5 

The address list pointer is provided in response to the 
EMS API verb. It is a pointer to the destination address 
list area, which is as long as the length of an address, 
say (8) times the number of ID's. The application must 
10 not change this value but needs to use it to fill in the 
destination network addresses or to retrieve them, as 
appropriate. On incoming messages to an application, 
there is only a single address* The format of the pointer 
is also platform-dependent. 

15 

Local User ID 



The local user ID field contains the name of the current 
local user (as contained in the USER configuration file). 
20 It is provided for application reference only for sending 
and receiving, but may be used for further queue 
qualification on other types of EMS API verb executions. 
It also may be an 8-character field. 
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Hessage Identifier 

The message identifier In an EMS-generated field ts used 
uniquely to identify every EMS message. It is assigned by 
the EMS API verb GET BUFFER for each message. The plat- 
form name is taken from the EMS Registration configuration 
information. 

Receipt Requested Mode 



10 



The receipt requested mode indicates whether intermedin 1 
hops are to send EMS commits for this message. The de- 
fault for outgoing messages is taken from the LOCALICB 
configuration file, this field being also part of the 
15 c 1 as s- o f - se r v i c e determination. 

EMS Mode 

The EMS mode indicates an overall transport priority based 
20 upon the object type; for example, express for normal 

messaging, and bulk for larger object transmissions. This 
field is included for future expansion purposes, with the 
default value being taken from the LOCAL ICB configuration 
i n f o rma t i on . 
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Resubmit Indicator 



The resubmit indicator is used by EMS to determine if 
retries on hop transmissions are to be executed. The 
default is taken from the LOCAL - ICB configuration 
information. On incoming messages, this indicator is "0 
if this is the original transmission, and "1" if it is a 
retried transmission. 



10 Request Code 

The request code defines an inquiry request to EMS for 
other than sending and receiving messages. 



15 Number of Desired Retries 

This field indicates the number of desired retries between 
hops. The default is taken from the LOCALICB configura- 
tion information. The sending application may change 
20 this value, which is a short integer. 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 9511560A1_L> 



WO 95/11560 



PCT/IB94/00322 



-7 !- 

Return Code 

The EMS status and purge type verbs return parameters and 
status codes. Depending on the verb, the values are 
5 placed in return code field. 

Retry Period 

The retry period is the number of seconds which the EMS 
10 Router will wait to receive a commit from the next hop for 
an outgoing message before reinitiating the transmission 
via the communication manager. There is a minimum time 
which is allowed based on the communication medium 
involved (service configuration information). The default 
15 is filled in from the LOCALICB configuration file for a 
GETBUFFER verb. 

Message Completion Process 

20 The name of the process to handle all the messages which 
are completed is entered in this field. The default is 
taken from the LOCALICB configuration ilc. If the 
process name is not provided, completed messages are not 
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enqueued for any other application. The process is 
translated into a queue name from the APPLICATION config- 
uration information. If there is no entry in this file 
for the specified application, the message is enquequed to 
5 the specified name. 

Message Time Out Process 

Message time out process is the name of the process to be 
10 called to handle all messages that do not receive either a 
commit within the retry period or that reach a completed 
state before the expiration period. The default is taken 
from the LOCALICB configuration file. If the process name 
is not provided, completed messages are not enqueued for 
15 any other application. The process is translated into a 
queue name from the application configuration informa- 
tion. If there is no entry in the configuration file for 
the specified application, the message is enquequed to the 
specified name* 

20 
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Message Time Out Request ID Process 

Message time out request ID process is the name of the 
process to handle all messages that do not receive either 

5 a commit within the retry period or that reach a completed 
state before the expiration period. The default Is taken 
from the LOCALICB configuration file* If the process name 
is not provided, completed messages are not enqueued for 
any other application. The process is translated into a 

10 queue name from the application configuration informa- 
tion. If there is no entry in the configuration file for 
the specified application, again, the message is enqueued 
to the specified name. 

15- Time Sent or Received 

For incoming messages, the time received is filled in by 
EMS. For outgoing messages, the time sent is filled in by 
EMS. This is a reference field for the application. 
20 Format of the time is the same on all platforms* 
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Scheduled Time 

If an application desires to defer a message until a 
specified time, then the date and time for the initial 
5 attempt are entered in this area. If no values are enter- 
ed here, the message will be sent as soon as the selected 
communication medium becomes available and all higher 
priority messages for that medium which are ready (not 
delayed for retry) have been sent. 

10 

Details of EMS API Verb Operation 



While the identification of EMS API verbs and their 
usage has been discussed, further details as to their 

15 format, function and uses for various applications and 
platform differences is now in order. 

Turning, first, to the COMMIT API verb, it, as be fore 
explained, Figs. 3, is used to inform a sending EMS Router 
that a complete message has been successfully received and 

20 processed as required and that the message resources 

(i.e. delete the message and related queue data), both 
local and remote, may now be released. Message status 
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is also updated. User and application requests for return 
r e ce i p t / g ua r a n t e e d delivery are made by setting the 
confirmation mode field in the net-work ICB. When the 
message is received by the EMS Router on the receiving 

5 computer, it uses the COMMIT verb to return a receipt 
acknowledgement to the sender (user or application). 
Alternatively, a receiving user or application can call 
COMMIT to send an acknowledgement message to a sending 
user or application following message receipt and 

10 processing. By this means, EMS can provide end-to-eud 
message delivery acknowledgements. COMMIT is also used 
between EMS Routers to provide hop (internal) delivery 
acknowledgements. 

Thus, in the flow chart of Fig. 8 t after checking the 

15 call parameter validity and using the ICB message pointer 
to locate the QCB (queue continue block), such is enqueued 
and the EMS Router is notified to issue the proper acknow- 
ledgement* The message buffers are then freed and the QCB 
de-queued . 

Considering now the DELETE verb. Fig. 9, such, it 
will be recalled, allows the removal of one or more 
selected messages from a specified queue (destination) 



20 
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regardless of priority, pending or active state or whether 
receipt has yet been acknowledged, A user or application 
may occasionally discover messages still in a queue await- 
ing destination availability that are no longer valid, 
5 that have a destination no longer in existence (user, 

application or system), or that have a destination known 
to be experiencing extended unavailability. The DELETE 
verb allows such messages to be removed by the user or 
application . 

10 Following call parameter validity check and QCB pool 

enqueuing, the active QCB with the input 1CB queue name is 
located, Fig- 9. If an active QCB is found, following 
enqueuing, each segment attached to the QCB is connected 
to a free list and the active QCB and the QCB pool are 
dequeued. If, on the other hand, an active QCB is not 
found, the QCB pool is thereupon dequeued, and the return 
code is to e rror . 

To accommodate for platform differences, since DELETE 
might cause unpredictable results if operating on a queue 
being accessed by another process in a multi-processing 
environment, it will reserve the queue to allow itself 
exclusive use of the queue while it is deleting records. 
Any other process sending or receiving from the queue at 



15 
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Che same time is suspended temporarily. This is a special 
internal transient state that exists only for the duration 
of the DELETE operation. The external state of the queue 
will remain as it existed prior to the commencement of the 
5 DELETE operation. 

The FREE BU F verb, before discussed, is called by an 
application to free resources: 

(a) allocated by GETBUF for STATUS calls, 

(b) allocated by GETBUF for STATE calls, 

10 (c) passed to the user via the RECEIVE call for incoming 
message delivery where a COMMIT is not issued, and/or 

(d) allocated by GETBUF for outgoing messages not passed 
on to the Router (i.e., cancelled). 



15 



Whenever an application receives a message or checks 
message status or queue state, EMS creates data storage 
areas and queue entries. 



20 
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Th ese resources must be released using the FREEBUF verb, 
Fig. 3, after they are no longer required - after a 
message has been received and processed by the application 
and after each STATUS and STATE call. Ap plication 
5 programs use the FREEBUF verb to release the resources 
associated with the API buffers allocated by GETBUF and 
message receipt. FREEBUF releases the local and network 
ICB and message data areas for messages, as well as the 
Queue Entry Block. FREEBUF also validates the input 
10 message buffer to ensure that the resources are not 

associated with a message in progress (on the outbound 
queues), returns the buffer to the free buffer pool, and 
releases any other resources associated with the message. 

Referring to Fig. 10, following call parameter, input 
15 buffer and message state validation, if the input buffer 
is temporary, it is returned to the operating system; but 
if a segment buffer condition exists, the buffer is 
returned to free segment node and the return code is set. 

20 



BNSDOCID: <WO 951 1560A1_I_> 



SUBSTITUTE SHEET (RULE 26) 



WO 95/11560 



PCT/TB94/00322 



-79- 



In Fig. II, the flow of the GET B UF verb operation is 
outlined, this verb, as previously described, allocating 
internal EMS memory and/or other resources needed to 
support the SEND, STATE, and STATUS services of EMS. 
5 Application programs must use the GETBUF subroutine, 

Fig. 3, to allocate all EMS API buffers needed to SEND 
messages, to retrieve queue STATE and to obtain STATUS for 
an individual messages. GETBUF returns an empty message 
buffer that carries ICBs loaded with default values. By 
10 securing message resources with GETBUF prior to issuing a 
SEND call, an application can be assured of having the 
necessary resources available for message delivery. This 
feature is especially important for very long messages 
that may at certain times exceed available resources. 
15 GETBUF interrogates the message buffer pool for 

available resources. If the requested size is greater 
than the maximum size, GETBUF returns an error. If the 
requested size is less than or equal to the maximum size, 
GETBUF locates a free buffer in the message segment pool 
20 and returns it to the calling program. If GETBUF cannot 
locate a temporary buffer or segment, it returns error to 
the calling program. GETBUF accepts a message length of 
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0 for use prior to STATUS and STATE calls. 

As summarized in Fig. 11, following call parameter 
validity check and enqueueing the segment pool, the next 
free segment is located and the return buffer pointer and 

5 return code set. If, however, no free segment is found, a 
return error code is set. 

The INITIALIZE verb, as before explained, connects 
the calling application process to the EMS infrastructure 
by creating and initializing one or more EMS Router queues 

10 (normally, a send queue and a receive queue) for the 

calling process. The INITIALIZE, Fig. 3, establishes the 
connection between an application and the EMS infra- 
structure. It must be called before any other EMS API 
calls are made - usually, at the time the application 

15 itself is initialized. INITIALIZE creates and initializes 
one or more queues managed by the EMS Router and notifies 
the EMS Communications Manager CM to initialize appro- 
priate EMS Communication Agents, Figs. 2 and 4, so that 
the message traffic to and from the application may begin. 

20 
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INITIALIZE first looks for an existing queue for the 
application process - one which may have been established 
during system initialization and configuration. If the 
queue already exists, . INITIALIZE locates the existing 

5 quetie control block (QCB) and, after verifying that no 

other active application process has issued an INITIALIZE 
for that queue (depending on environment), connects the 
queue with the calling process (mechanism dependent on 
environment). If an existing queue is not found, on the 

10 other hand, INITIALIZE creates one and then goes through 
the same connection process. 

INITIALIZE further opens the appropriate files (mail- 
boxes) for the designated queues based on the EMS Configu- 
ration Files and the operating environment. If the queue 

15 file for the designated queue already exists, then it is 
read from the media and QEB ' s are built for the messages 
contained in the file. If no queue file exists for the 
requested queue, one is established and a QCB is set up 
with null pointers in the QEB entries. 

20 Depending on the environment, moreover, a "wake-up" 

Is issued for the EMS Communication Manager CM, Figs. 2 
and 4. If the CM is already running, this call has no 
effect; otherwise, the CM is started. INITIALIZE does 
not, however, wait for the CM to start before continuing. 
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It is not necessary, furthermore, for any application 
to issue INITIALIZE if all of the queues for a platform in 
any environment are defined in the configuration file9 as 
static queues. Existing queues may be memory-based , disk- 

5 file based using environment conventions, or resident in a 
database, or a combination of all of these. The exact 
implementation of the queues does not affect the basic 
functionality of the EMS processes or the API verbs. 
Whenever the enviroment supports it, messages will be 

10 written to auxiliary media (disk) if they are designated 
as recoverable. The queue name length is specified in 
irartrext.h. It must not be changed for DOS or WINDOWS 
implementation as It is used to build a queue file name. 

After call parameter check, Fig. 12, and enqueueing 

15 the QCB pool, the active QCB with the appropriate input 

process queue name is located and enqueued. If it is true 
that the active QCB owner is not calling the process (and 
there is not a null), the active QCB is dequeued and the 
return code is set to error; but if such is not true 

20 (false), the active QCB owner is set to calling process, 
an active QCB name and a maximum message count, and then 
the QCB is dequeued and return is effected. This latter 
sequence is also ordered if the active QCB is not found 
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and a free OCB is enqueued and connected to the active QCB 
list. Should no free QCB be found, however, the return 
code is set for error. 

Turning now to the previously described PURGE verb, 
5 such allows an application to remove all messages from any 
local queue regardless of priority and regardless of pend- 
ing or active state* 

An application may find it necessary or desirable in 
rare instances to remove all of the messages from one of 
10 its EMS Queues- This might occur if the computer runs low 
on resources and needs to free up memory, if the user 
learns that a particular destination (queue) is no longer 
available, or if the user wishes to clear all messages 
from a particular sender (i.e, without receiving them), A 
15 PURGE call for the queue name will delete all messages for 
that destination or sender. 

As shown in Fig. 13, after validating the input para- 
meters, PURGE enqueues the QCB pool and locates the QCB 
with the input 1CB queue name. If the QCB is found, PURGE 
20 frees all message segments for all priorities chained to 

the QCB , and then frees the QCB itself, setting the return 
code to SUCCESS. If the input QCB is not found, however. 
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PURGE returns an error code to the caller. 

The RECEIVE verb is used to effect delivery of an 
incoming message to the destination application or user 
and to query the EMS Router about traffic awaiting 

5 delivery to this destination. The first message of the 

highest priority awaiting delivery is returned in the ICB 
and the return code in the local ICB is set to the number 
of remaining messages that are to be retrieved, Figs. 4 
and 6. Since every application is different, it is 

10 necessary for the individual application to be able to 
control when and how it receives incoming messages 
addressed either to itself or to the current user. The 
RECEIVE verb, provided for this purpose, allows applica- 
tions to call for messages only when the application 

15 (user) is ready to process the message. 

RECEIVE validates the input parameters, Fig. i 4 t and 
allocates the buffer space necessary for the ICB areas and 
the message segment. Depending on the configuration para- 
meters, RECEIVE then moves the data from each segment into 

20 the receive buffer to build the complete message, or 

returns the message segments to this application, one at a 
time, as independent datagrams. Thus, after locating the 
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highest priority message and optional segment size, either 
each message segment is moved to temporary message buffer 
and then sets the return buffer, or the return buffer is 
set from the message segment buffer enabling a change in 
5 message state, if needed, to PENDING COMMIT. In the event 
there is no message count (0), the QCB is thereupon 
dequeued and the return order code set to error. 

RECEIVE returns the pointer to the local ICB, which, 
in turn, contains the pointer to the network ICB and 
10 message data areas. The application has addressability to 
each area. The return code field of the local ICB con- 
tains the number of messages enqueued for the application 
(not counting this one). 

The SEND verb permits an application to place a 
15 message into the EMS Router Queue for eventual trans- 
mission to the specified destination. The application may 
then go on to do other work. It does not have to waft 'for 
the message transmission to complete. Messages created by 
application are handed to EMS using the API's SEND verb. 
20 SEND thereupon causes a message to be placed on the EMS 
Router Queue for the specified destination where it will 
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await processing based on instructions in the local and 
network ICBs and the EMS Configuration Files. SEND places 
an application message on the "send queue" assigned to 
that application and user, and performs only the basic 

5 formatting error checks such as field presence or absence, 
and pointer range. All other local and network ICB checks 
and audits are performed by the EMS Router using the con- 
figuration values. 

Even in an environment such as MS-DOS, the message 

10 processing after the SEND function is completed proceeds 
in background to the user applications. It should be 
noted, moreover, that the EMS Communication Manager CM, 
Figs. 2-4 , also uses the SEND verb to pass incoming 
messages to the EMS Router for further direction (to a 

15 local app li ca t ion/ use r or to the next node in the net- 
work). 

In Fig. 15, accordingly, after call parameter and 
input ICB validation, the work queue name is set to 
destination node and process name and the QCB pool is 
20 enqueued . If an active QCB using the work queue is loca- 
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ted , unconditional enqueueing of the active QCB is effect- 
ed and the pool dequeued, with the return code set to 
SUCCESS. If such an active QCB is not found, a free QCB 
is enqueued and connected to the active ()CB list before 
5 the pool is dequeued and SUCCESS indicated. Should them 
be no free QCB, however, the return code is set to error. 

The before-described STATE verb allows an application 
process to inquire about or to alter the state of any 
local EMS Router queue. Application programs can use the 
10 STATE verb to alter the state of an EMS queue or to 

inquire about the state of a queue. During certain times, 
an application program (or the user) may, for example, 
wish to allow only the queueing of incoming messages, but 
to disable sending of message until the state is changed. 
15 The local ICB carries queue status as part of its 

normal data. When an application program calls STATE to 
alter the queue state, it must first place the desired 
state in the local ICB (obtained using a GETBUF call), A 
STATE call returns with the altered state of the queue, if 
20 successful. When an application program calls STATE to 
inquire on the state of a queue, STATE updates the ICB 
with the actual state of the queue which can then be read 
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by the application. The EMS Router queue 9tate processor 
(STATE function) allow two operations to be performed on 
single queue - either inquiry or update of queue state. 
The local 1CB for the verb update includes the reason code 

5 and the state change. 

The STATU S verb allows an application to inquire 
about or alter the status of any message in the named send 
queue and to obtain the number of messages in the queue. 
In general, application programs will not need to use the 

10 STATUS verb. STATUS should be used by application pro- 
grams only in environments where message acknowledgements 
are not returned to application programs and there is no 
generally available way supported by the environment to 
notify the program when an event has occurred. For 

15 example, in some enviroments it is necessary for the send- 
ing application to "poll" the EMS Router to see if an out- 
going message has been completed (older MS-DOS). When 
needed, however, STATUS allows the queue state of any 
message entry in the queue to be read or modified* 

20 
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STATUS first validates the local ICB. If the call In- 
dicates a status inquiry, STATUS returns message status in 
the local ICB passed by the calling program. If the call 
Indicates a status change, STATUS verifies that the 

5 current status is accurately set in the request ICB by the 
calling program. If the current status is properly 
depicted by the calling program in the ICB, STATUS 
attempts to make the status change indicated. If the 
status change requested is logically incorrect, STATUS 

10 reports an error to the calling program. 

In Fig. 16, therefore, following location of an 
active QCB with the input queue name and a code field 
request check, a status inquiry may be effected by copying 
the QCB status data in the ICB input. For a status 

15 change, on the other hand, the ICB is enqueued and either 
the ICB new state is moved to the current state and then 
the <JCB is. dequeued, or the QCB dequeueing is directly 
effected and the return code set to error. 

Before application exit, TERMINATE is called to clean 

20 up, resolve latent messages, and terminate the application 
EMS Router queue connection. The TERMINATE verb dis- 
connects an application process from the EMS queueing 
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inf rastructure. TERMINATE deactivates the EMS Router 
queue (previously created by INITIAL IZE) and causes LogOff 
messages to be sent to attached networks if the queue is 
"send" or "receive'* (this is done at application termina- 

5 tion processing time only). TERMINATE releases the re- 
sources, associated with the input and output queue 
connections for the calling process* This verb must be 
called before exiting the application in order to Insure 
queue integrity and orderly communications close-out, 

10 TERMINATE, furthermore, logically disassociates the call- 
ing process from the EMS Router queue described by the 
input queue handle. It first checks for messages on the 
calling process Router queue* If there are no messages, 
TERMINATE frees the queue control block* If there are 

15 messages, they are either saved as directed in the config- 
uration files, or discarded. 

Referring to Fig. 17, accordingly, upon locating an 
active QCB with the appropriate input queue name and 
enqueueing the ICB , if the calling process is the active 

20 QCB owner ("yes") and is not a null, after setting the 

queue owne r to null, active messages are either saved be- 
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fore dequeueing the QCB, r if there are no active 
messages, the QCB is connected to free QCB list before 
dequeueing. Otherwise, the return code is set to **rror . 

The invention, thus, in addressing business needs of 

5 supporting enterprise integration and worker/ task/work- 
place mobility, and integrating incompatable networks with 
multi-media, multi-network and multi-platform needs, 
provides a consistent and cost-effective solution through 
its providing of vendor and platform independence, guaran- 

10 teed data/message delivery, and transparent interchange of 
multi-media data, with fully recoverable store-and-f orward 
transfers and the broadest connectivity availability. 

EMS equipment designed in accordance with the inven- 
tion, as currently constructed, supports the operating 

15 environments, for the designated communications services 
and media shown in Fig. 18, with additions to this envir- 
onment list to include UNIX System V Release 4 and 
Macintosh System 6.04 and others. Palmtop units running 
MS-DOS 3.3+ are also supported. Cellular modem support 

20 may be provided, also, for all environments that currently 
support dial— up asynchronous communications, and connect- 
ivity extensions to platforms Including the Microsoft NT, 
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DEC ULTRIX, HP-UX and Sun-OS are useable with the inven- 
tion, also; demonstrating the wide scope of the universal, 
generic or heterogeneous approach of the invention. 

Further modifications will also occur to those 
5 skilled in this art, and such are considered to fall with- 
in the spirit and scope of the invention as defined in the 
appended claims. 



10 
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CLAIMS 

1. A method of electronically messaging between compu- 
ters by he terogeneously and universally interfacing dis- 
tributed applications and processes residing in a wide 
variety of differing computer platforms and communications 

5 transport facilities of various types, that comprises, 

providing a set of s i ng 1 e- f u n c t i on software modules con- 
trolled by a preselected set of verbs that together pro- 
vide a consistent application programming interface 
between the applications/process and the communications 

10 facility and through which application prog rams / proces se s 
can access the electronic messaging; under the control of 
the set of module verbs, first queueing and routing mes- 
sages and data flowing from and to the sending and recov- 
ering computer applications/processes and monitoring the 

15 delivery status thereof, and then communicating the routed 
messages and data through a communication agent for each 
communication transport facility; and providing common 
messaging functions for all communication agents indepen- 
dently of and without user concern for the specifics of 

2° the various communications facilities and their character- 
istics. 

2. A method as claimed in claim I and in which the 
module verbs are used to provide for message transfer and 
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recelpt, message managing and queuing, and environment 
resource allocating and deallocating. 

3. A method as claimed In claim 2 in which the managing 
of the data/message comprises managing queues for routing 

5 outgoing and incoming data/message transmission and 

delivery, and notifying applications of message status 
changes . 

4. A method as claimed in claim 3 wherein, on startup, 
queues for the d a t a /me s sa ge s are rebuilt from saved files; 

10 and, on shutdown, d a t a/ me s s age s which have not been 

completed and are saveable are entered into such saved 
files. 

5. A method as claimed in claim 3 and in which, if the 
application for a designated user is not active, the 

15 application process is started to deliver the incoming 
data/mesBage . 

6. A method as claimed in claim 1 and in which each said 
communication agent manages the passing of data/messages 
to and from its communications transport facility. 

20 7. A method as claimed in claim 1 and in which data/ 

messages, particularly of substantial length, are segment- 
ed for sending and are reassembled upon receipt, with seg- 
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ment length optimised in accordance with the particular 
communications transport facility. 

8. A method as claimed in claim 7 and in which a message 
header is applied between the app 1 i ca t i on / pr o c e s s and the 

5 module-verb interface to encapsulate prefix header control 
data with the message to identify the ultimate destination 
of the data/message and to provide a tag or name for 
selecting the particular data/message. 

9. A method as claimed in claim 8 and in which there is 
10 included in the message header all data needed to route, 

acknowledge or confirm, and recover the electronic data/ 
messages as they move from sender to destination. 

10. A method as claimed in claim 9 and in which the 
message header data controls how the data/message is to be 

15 handled and further enables adding and dropping informa- 
tion as and when needed or no longer required, including 
by the c o mm unications facility. 

11. A method as claimed in claim 7 and in which the 
message segments are subdivided into message pockets 

20 corresponding substantially to the maximum handlable by 
the particular communications facility. 
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12. A method as claimed in claim 1 1 and in which the message packets are 
combined in preselected frames prior to sending over the communications 
facility. 

13. An electronic messaging system for communicating between computers 
and the like with heterogeneous and universal interfacing between distributed 
applications and processes residing in a wide variety of differing computer 
platforms and communications transport facilities of various types, having, in 
combination, means for providing between an application/process and a 
communications facility a set of single-function software modules controlled by a 
preselected set of verbs that together provide an application programming 
interface through which application programs/processes can access the electronic 
messageing by an interface control block; message routing means controlled by 
the application programming interface control block for staging messages and 
data flowing from and to the sending and receiving computer 
applications/processes by a router control block for determining message 
handling and communications facilities, and monitoring the message delivery 
status; communication agent means, one corresponding and connected to each 
communication transport facility, controlled by common communication 
management means connected to the routing means and responsive to its said 
router control block to control the message flow from each communication agent 
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means to its corresponding communication transport facil- 
ity independently of and without user concern for the 
specifics of the various communications facilities and 
their characteristics. 

14. An electronic messaging system as claimed in claim 13 
and in which the application programming Interface verbs 
comprise a set for message transfer and receipt, a set for 
message managing and queueing, and a set for environment 
resource allocating and deallocating. 

15. An electronic messaging system as claimed in claim 14 
and in which which means is provided controlled, by the 
communications management means for providing the message 
with a header containing data needed to route, acknowledge 
or confirm, and recover the electronic data/messages as 
they move from sender to destination* 

16. An electronic messaging system as claimed in claim 15 
and in which the header providing means further provides 
information to control how the data/message is to be 
handled and enables adding and dropping information as and 
when needed or no longer required, including by the commu- 
nications facility. 

17. An electronic messaging system as claimed in claim 13 
and in which means is provided for segmenting the 
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data/messages for sending and for reassembling upon 
receipt, with segment length substantially optimized in 
accordance with the particular transport communications 
f acili ty * 

5 18- An electronic messaging system as claimed in claim 17 
and in which means is provided for subdividing the message 
segments into message packets. 

19- An electronic messaging system as claimed in claim 18 
and in which means is provided for combining the message 
10 packets in preselected frames prior to sending over the 
communications facility, 

20, An electronic messaging system as claimed in claim 13 
and in which means is provided for enabling the verbs of 
said application programming interface modules selectivity 

15 to effect one or more of the following functions: COMMIT, 
to inform the routing means that a complete message has 
been successfully received and processed as required, and 
that the message and its related queue data may be re- 
leased; DELETE, to remove one or more selected messages 

20 from a specified queue regardless of priority, pending or 
active state, or whether receipt has yet been acknow- 
ledged; FREE B UF , to release data/storage and queue entries 
when no longer required: GET BUF , to allocate resources 
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such as internal memory needed to support message sending 
and status services; INITIALIZE, to connect the calling 
application or process for electronic messaging; PURGE, to 
remove all of the messages from any local queue regardless 
5 of priority and pending an active state; RECEIVE, to de- 
liver an incoming message to destination application and 
to queue the message traffic awaiting delivery and prior- 
ity to such destination; SEND , to place a message into 
routing queue for eventual sending to the specified des- 
10 tination; STATE, to Inquire about or alter the state of 

any local routing message queues; STATUS, to inquire about 
or alter the status of any message in the named message 
sending queue and to obtain the number of messages in such 
queue; and TERMINATE , to resolve latent messages before 
15 application exit and then terminate the application 
connection to the routing message queue. 

21. An electronic messaging system as claimed in claim 13 
and in which means is provided for enabling the verbs of 
said application programming interface modules selectivity 

90 

resources to effect one or more of the following func- 
tions: (1) to inform the routing means that a complete 
message has been successfully received and processed as 
required, and that the message and its related queue data 
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released; (2) to remove one or more selected messages from 
a specified queue regardless of priority, pending or 
active state, or whether receipt has yet been acknow- 
ledged; (3) to release data/storage and queue entries when 

5 no longer required: (A) to allocate resources such as 
internal memory needed to support message sending and 
status services; (5) to connect the calling application or 
process for electronic messaging; (6) to remove all of the 
messages from any local queue regardless of priority and 

1° pending an active state; (7) to deliver an incoming 
message to destination application and to queue the 
message traffic awaiting delivery and priority to such 
destination; (8) to place a message into routing queue for 
eventual sending to the specified destination; (9) to 

^ inquire about or alter the state of any local routing 

message queues; (10*) to inquire about or alter the status 
of any message in the named message sending queue and to 
obtain the number of messages in such queue; and (11) to 
resolve latent messages before application exit and then 

20 terminate the application connection to the routing 
message queue* 
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22. A method of heterogeneous connectivity and universal 
and generic interfacing for distributed applications and 
processes residing in a wide variety of computing plat- 
forms communicating over varied communications transport 

5 facilities, that comprises, interposing between the 

computer platforms and the varied communications facili- 
ties, a common application programming interface of 
s ingl e- f unc t i on software modules controlled by preselected 
verbs, that upon separate actuation, provide a common 

10 control of message/data recovering, security and directory 
services irrespective of the varied protocols and idio- 
syncrasies of the varied communications facilities, iso- 
lating the applications/ processes from such protocols and 
idiosyncrasies and effecting message/data handling by the 

^ programming of the common interface modules* 
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